<%@ Page Language="VB" MasterPageFile="~/masterpages/dev.master" AutoEventWireup="false" CodeFile="Default.aspx.vb" Inherits="dev_Default" title="Untitled Page" %>
<asp:Content ID="Content1" ContentPlaceHolderID="ContentPlaceHolder1" Runat="Server">
    <h2>Project Details</h2>
    <p>
        As I'm prone to do every couple months, I want to rewrite FSTDT.com from scratch. 
        However, I want to try something new: I want to make the FSTDT sourcecode available to
        everyone, so that this site has multiple pairs of eyes scouring the sourcecode looking
        for areas of improvement. I want FSTDT.com to be an opensource project written in
        C# and VB.Net.
    </p>
    
    <h2>This Site Sucks Ass</h2>
    <p>
        Because, basically, the site wasn't designed well from the start. I've written every 
        incarnation of this site too hastily: the first version of the FSTDT.com forum was 
        put together in 2 1/2 days. So, I introduced a lot of bugs; I cleaned them up, but in 
        the process, I created more bugs.
    </p>
    <p>
        As I mentioned in <a href="http://www.fstdt.com/forums/thread.aspx?t=70131">this thread</a>,
        the site suffers from two major problems:
    </p>
        <ol type="1">
            <li>
                <p>
                <b>No Unit Tests</b>
                </p>
                <p>
                When I make changes to code, its hit or miss. I have a copy of FSTDT on my local 
                machine, so I can see the effects of changes; and that usually determines whether 
                something gets uploaded to the site. But that's not a good way to design sites as 
                large as FSTDT.
                </p>
                <p>
                For those of you unfamiliar with unit testing, the idea behind it basically works 
                like this:<br />
                - everytime you want to add some functionality to code, you write a "test" for 
                it. For example, to test my YCode class, I would create a few sample codes, then 
                I would write a few tests to test the range of different inputs and expected 
                outputs.
                </p>
                <p>
                - if I changed my YCode module, or if I added another class that the YCode module 
                depends on (like an XML reading class), I need to know how those changes affect 
                the code that's already in place. So, I run the tests that I've written; if they 
                all pass, good. If not, I need to know why.
                </p>
                <p>
                - Over time, tests accumulate. 1000s and 1000s of tests can exist for a single 
                project. The end result is that, provided you've written tests for everything, 
                you have very well-tested code, and you know exactly what changes to code causes 
                things to break.
                </p>
                <p>
                FSTDT.com has no unit tests. I want to fix that.
                </p>
            </li>
            <li>
                <p>
                <b>No Data Abstraction</b>
                </p>
                <p>
                Data Abstraction is a simple concept: programmers shouldn't have to write their 
                own sql queries. Programmers should rely on a framework that puts as much distance 
                between them and sql queries as possible; the data access framework should write 
                the queries for the programmer. That way, programmers only need to worry about 
                the logic of their applications, where changes to the database have negligible 
                impcact on the code.
                </p>
                <p>
                FSTDT.com has no concept of data abstraction yet. The site relies on a few dozen 
                stored procedures for everything. That means, if I want to change a column in a 
                table, I have to edit dozens of stored procedures; and I have to edit dozens and 
                dozens of pages whereever that column is used on the site. (And since I have no 
                unit tests, I'll never know if I've missed a section!)
                </p>
                <p>
                FSTDT is not a large site by any means, but even the trivial act of renaming a 
                column is prone to break a lot of things, and its time consuming to track down 
                all the places where a change might break something. My stored procedures are a 
                mess, and I've wante to get rid of them for a long time.
                </p>
                <p>
                I wrote some prelimenary code for data abstraction; I'm going to tweak it over 
                the next few hours, then I'll release it on FSTDT.com for code review, along 
                with an explanation of why its needed and how to use it. 
                </p>
            </li>
        </ol>
    <p>
        The newest incarnation of the site is <i>usable</i>, as long as you know where to click.
        But the site is a tragedy as far as I'm concerned; I made quick development decisions 
        instead of smart ones. I want to start fresh, with definite goals in mind, proper planning,
        and appropriate design.
    </p>
</asp:Content>

